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Media Type Registration Procedure 
Status of this Memo 


This memo provides information for the Internet community. This memo 
does not specify an Internet standard of any kind. Distribution of 
this memo is unlimited. 


Abstract 


Several protocols allow the use of data representing different 
"media" such as text, images, audio, and video, and within such media 
different encoding styles, such as (in video) jpeg, gif, ief, and 
tiff. The Multimedia Internet Message Extensions (MIME) protocol [1] 
defined several initial types of multimedia data objects, anda 
procedure for registering additional types with the Internet Assigned 
Numbers Authority (IANA). Several questions have been raised about 
the requirements and administrative procedure for registering MIME 


content-type and subtypes, and the use of these Media Types for other 


applications. This document addresses these issues and specifies a 
procedure for the registration of new Media Types (content- 
type/subtypes). It also generalizes the scope of use of these Media 


Types to make it appropriate to use the same registrations and 
specifications with other applications. 


1. Introduction 


RFC 1521 [1] defines a procedure for the registration of new data 
types for use with the Multimedia Internet Message Extensions (MIME). 
This registration mechanism was designed to make the identifiers for 
a given data type available for use and to prevent naming conflicts. 
With the growth of new multi-media protocols and access mechanisms, 
this process has the promise of forming a unified general 
registration service for Internet Protocols. These types, previously 
called "MIME Types", are now called "Media Types". 


The registration process for Media Types (content-type/subtypes) was 
initially defined in the context of the asynchronous mail 
environments. In this mail environment, there is a need to limit the 
number of possible Media Types to increase the likelihood of 
interoperability when the capabilities of the remote mail system are 
not known. As Media Types are used in new environments, where the 
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proliferation of Media Types is not a hindrance to interoperability, 
the original procedure is excessively restrictive and needs to be 
generalized. 


This document addresses the specific questions raised and provides an 
administrative procedure for the registration of Media Types. This 
procedure also address the registration requirements needed for the 
mapping of Object Identifiers (OIDs) for X.400 MHS use to Media 
Types. 


2. Media Type Registration Procedure 


The following procedure has been implemented by the IANA for review 
and approval of new Media Types. This is not a formal standards 
process, but rather an administrative procedure intended to allow 
community comment and sanity checking without excessive time delay. 


2.1 Present the Request for Registration to the Community 


Send a proposed Media Type (content-type/subtype) to the "ietf- 
types@cs.utk.edu" mailing list. This mailing list has been 
established for the sole purpose of reviewing proposed Media Types. 
Proposed content-types are not formally registered and must use the 
"x-" notation for the subtype name. 


The intent of the public posting is to solicit comments and feedback 
on the choice of content-type/subtype name, the unambiguity of the 
references with respect to versions and external profiling 
information, the choice of which OIDs to use, and a review of the 
security considerations section. It should be noted that the 
proposed Media Type does not need to make sense for every possible 
application. If the Media Type is intended for a limited or specific 
use, this should be noted in the submission. 


2.2 Submit the Content Type to the IANA for Registration 


After two weeks, submit the proposed Media Type to the IANA for 
registration. The request and supporting documentation should be 
sent to "iana@isi.edu". Provided a reasonable review period has 
elapsed, the IANA will register the Media Type, assign an OID under 
the IANA branch, and make the Media Type registration available to 
the community. 
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The Media Type registrations will be posted in the anonymous FTP 
directory "ftp.isi.edu:in-notes/media-types" and the Media Type will 
be listed in the periodically issued "Assigned Numbers" RFC [2]. The 
Media Type description may be published as an Informational RFC by 
sending it to "rfc-editor@isi.edu" (please follow the instructions to 
RFC authors [3]). 


Clarifications On Specific Issues 


3.1 MIME Requirements for a Limited Number of Content-Types 


Issue: In the asynchronous mail environment, where information on 
the capabilities of the remote mail agent is not available to the 
sender, maximum interoperability is attained by restricting the 
number of content-types used to those "common" content-types expected 
to be widely implemented. This was asserted as a reason to limit the 
number of possible content-types and resulted in a registration 
process with a significant hurdle and delay for those registering 
content-types. 


Comment: The need for "common" content-types formats does not 
require limiting the registration of new content-types. This 
restriction may, in fact, hinder interoperability by causing separate 
registration authorities for specific applications which may register 
values in conflict with or otherwise incompatible with each other. 

If a limited set of content-types recommended for a particular 
application, that should be asserted by a separate applicability 
statement specific for the application and/or environment. 


3.2 Requirements for a Published Specification 


Issue: Content-Type registration requires an RFC specifying the data 
format or a reference to a published specification of the data 
stream. This requirement may be overly restrictive for the use of 
content-type registration for file attachments and distribution 
because a public specification may not be available for a number of 
widely used and exchanged objects. 


Comment: MIME required the documentation of a specific content-type 
to allow the unambiguous identification of a defined type. This 
intent is met by the identification of a particular software package 
and version when registering the content-type and is allowed for 
registration. The appropriateness of using a Media Type with an 
unavailable specification should not be an issue in the registration. 
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3.3 Identification of Security Considerations 


Issue: The registration process requires the identification of any 
known security problems with the content-type. 


Comment: It is not required that the content-type be secure or that 
it be free from risks, but that the known risks be identified. 
Publication of a content-type does not require an exhaustive security 
review, and the security considerations section is subject to 
continuing evaluation. Additional security considerations should be 
periodically published in an RFC by IANA. 


3.4. Recommendations and Standards Status 


Issue: The registration of a data type does not imply endorsement, 
approval, or recommendation by IANA or IETF or even certification 
that the specification is adequate. 


Comment: To become Internet Standards, protocol, data objects, or 
whatever must go through the IETF standards process. This is too 
difficult and to lengthly a process for the convenient and practical 
need to register Media Types. It is expected that applicability 
statements for particular applications will be published from time to 
time that recommend implementation of, and support for, data types 
that have proven particularly useful in those contexts. 


4. Security Considerations 


This memo does not address specific security issues but outlines a 
security review process for Media Types. 
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Appendix A -- IANA Registration Procedures for Media Types 


MIME has been carefully designed to have extensible mechanisms, and 
it is expected that the set of content-type/subtype pairs and their 
associated parameters will grow significantly with time. Several 
other MIME fields, notably character set names, access-type 
parameters for the message/external-body type, and possibly even 
Content-Transfer-Encoding values, are likely to have new values 
defined over time. 


In general, parameters in the content-type header field are used to 
convey supplemental information for various content types, and their 
use is defined when the content-type and subtype are defined. New 
parameters should not be defined as a way to introduce new 
functionality. 


In order to ensure that the content-type and subtype (that is Media 
Type) values are developed in an orderly, well-specified, and public 
manner, MIME and other applications use the registration process for 
Media Types defined in this RFC which uses the Internet Assigned 
Numbers Authority (IANA) as a central registry for such values. 


In order to simplify and standardize this Media Type registration 
process, this appendix gives templates for the registration of new 
values with IANA. Each of these is given in the form of an email 
message template, to be filled in by the registering party. 


Registration of New Content-type/subtype Values: 
Note that MIME is generally expected to be extended by subtypes. If 
a new fundamental top-level type is needed, its specification must be 


published as an RFC or submitted in a form suitable to become an RFC, 
and be subject to the Internet standards process. 
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IANA 


To: IANA@isi.edu 
Subject: Registration of new Media Type content-type/subtype 


Media Type name: 


(If the above is not an existing top-level Media Type, please 
explain why an existing type cannot be used.) 


Media subtype name: 

Required parameters: 

Optional parameters: 

Encoding considerations: 

Security considerations: 

Published specification: 

(The published specification must be an Internet RFC or RFC-to-be 
if a new top-level type is being defined, and must be a publicly 


available specification in any case.) 


Person & email address to contact for further information: 
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